The present invention is directed to a new architecture for software development, and more specifically to Shell architecture for software development in which the development of Logic is entirely separated from the development of Graphical User Interface (GUI).
Computer programs that interact with external resources have three constructs: Logic, Data, and Input/Output.                Logic is defined as the computer instructions that perform the desired task: for example, calculating the best move in a tic-tac-toe game application or determining illegal moves in a tic-tac-toe game application. Another example would be the process of making a connection between the “caller” and “callee” of a phone call.        Data is defined as a distinct piece of information: for example, an “X” or an “O” played in a tic-tac-toe board cell. Another example would be a telephone number that a user (“caller”) is trying to call.        Input/Output or (I/O) is defined as the mechanism for externally influencing and expressing a computer program: for example, the part that shows the tic-tac-toe board and allows a user to select a tic-tac-toe board cell. Another example would be the buttons and displays of the telephone. A Graphical User Interface (GUI) is defined as an I/O construct or unit that works via interactive display of information (including the Data defined above). The terms GUI and I/O are used substantially interchangeably throughout this application, although a GUI is just one type of I/O.Legacy Software Application Paradigm        
Early software developmental paradigms intermingle the Logic, Data, and I/O constructs. In other words, programmers programmed Logic, Data, and I/O altogether in one application. This was extremely inefficient. Further, it was extremely difficult for multiple programmers to work on a single application using this legacy paradigm. Still further, intermingling Logic, Data, and I/O in software development is considered non-viable today because software is simply too complex for a developer/programmer to be completely versed in the Logic, Data, and I/O constructs.
Typical Software Application Paradigm
Typical software developmental paradigms and many typical software applications (e.g. WINDOWS® and MAC®) use the Logic construct as a functional intermediary between the Data construct and the I/O construct. In this paradigm, as depicted in FIG. 1, Logic 10 is the key link between managing Data 12 and I/O 14. This paradigm was introduced as a basic programming architecture for the modern operating system. However, the developer/programmer of the Logic construct must not only have technical knowledge of the specific problem being solved, but also an equal technical knowledge of all aspects of the I/O construct.
Application Frameworks Paradigm
The next evolutionary stage of software developmental paradigms was the use of Application Frameworks 20 as shown in FIG. 2. This paradigm is very similar to the paradigm shown in FIG. 1, except that an Application Framework 20 is used to wrap the GUI 22 underneath. The Application Framework 20 can help with the automation of programming. As shown, Logic 26 remains the key link between managing Data 24 and the Application Framework 20.
The Application Framework 20 paradigm aids in the complexity of dealing with the proliferation of platforms because the Application Framework 20 will work with multiple platforms. In other words, using the Application Framework 20 paradigm, the programming may become portable over multiple platforms.
The Application Frameworks 20 paradigm, however, only replaces the need for technical knowledge of both the Logic 26 and the I/O 22 (as with the paradigm shown in FIG. 1) with the need for technical knowledge of both the Logic 26 and the Application Framework 20. In other words, the developer/programmer of the Logic construct must not only have technical knowledge of the specific problem being solved, but also an equal technical knowledge of all aspects of the Application Framework 20.
Model View Controller Architecture Paradigm
With the advent of Object Oriented Programming (OOP), the next paradigm came into fashion. In this paradigm, the Data and that part of the Logic that gives the Data domain-specific meaning were merged into an object known as the Model 32. The Graphical User Interface (GUI) module was split into two objects—the Controller 30 and the View 34. These objects have the following responsibilities:                Model 32 (FIG. 3)—The model object gives high-level meaning to the Data on which an operation is being performed. The Data is abstracted into domain-specific information, and can perform operations (e.g. “compute total taxes” or “enumerate shopping cart contents”).        View 34 (FIG. 3)—The view object renders the model into something with which the user can interact (e.g. a window, a filled-out form, a web page, etc.)        Controller 30 (FIG. 3)—The controller object processes events, generally in response to user actions, and updates the Model 32 accordingly. The controller object can also indirectly make changes to the View 34 (e.g. requesting a refresh).        
The primary advantage of this paradigm is encapsulation; modifications to one object component typically have a minimal impact on the other object components. The disadvantages are additional complexity and computational inefficiency. Additionally, interfaces between these object components are typically very wide (i.e. contain numerous functions and message types), and considerable up-front design must take place before development of the three object components can begin in parallel.